A service, such as a multi-tier application, may have various components that can be hosted, such as through compute instances (e.g., virtual machines), at particular infrastructure tiers of a multi-tier infrastructure. In an example, a first virtual machine executing at a server of a server tier may host a database of the service, a second virtual machine executing at an on-premises device of an on-premises tier may host an application server of the service, a third virtual machine executing within a cloud computing tier may host a backup data store of the service, etc.
The components of the service have static residence within the multi-tier infrastructure. That is, a component always executes at the same location (e.g., infrastructure tier) at which the component was installed. This is because the location of the compute instances hosting the components are generally defined as design time. A provider of the service may specify the location based upon the most stringent service levels (e.g., service level agreements) that may be required by the service at a particular point in time. Unfortunately, the inability to relocate components amongst different infrastructure tiers (e.g., amongst different types of infrastructure tiers or amongst different providers of a same type of infrastructure tier) can result in substantial loss of cost savings because the components may be located at relatively more expensive infrastructure tiers even during time periods where less expensive infrastructure tiers could satisfy a current service level for the service. At best, horizontal scaling can be performed where additional instances of a component could be created at the same infrastructure tier (e.g., multiple virtual machines may be created at the on-premises tier for hosting multiple instances of the application server), which still does not achieve cost effective deployment and hosting of the service because other different infrastructure tiers could satisfy the current service level at a reduced cost.